Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change error return values in WikiPage::getSection() and setText() (fixes #116) #129

Merged
merged 2 commits into from
Aug 26, 2021

Conversation

Xymph
Copy link
Collaborator

@Xymph Xymph commented Aug 26, 2021

See issue #116.

@Xymph Xymph requested a review from waldyrious August 26, 2021 15:37
@Xymph Xymph force-pushed the 129-error-return-values branch 2 times, most recently from 2af8629 to c1af34d Compare August 26, 2021 15:54
Copy link
Collaborator

@waldyrious waldyrious left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've left two suggestions, neither deal-breakers (so I'm marking the review as "comment" rather than "request changes").

CHANGELOG.md Outdated Show resolved Hide resolved
Wikimate.php Show resolved Hide resolved
@Xymph Xymph force-pushed the 129-error-return-values branch from c1af34d to d3e8e88 Compare August 26, 2021 18:37
@Xymph
Copy link
Collaborator Author

Xymph commented Aug 26, 2021

I went back and forth a bit on the changelog section header btw, hence the first pair of force-pushes. In the same section will be the error code change in login() and I didn't want to put the API-breaking warning in both Changed and Fixed sections. In this PR the getSection commit is more of a change and the setText commit is a fix, but altogether I eventually settled on the Changed section header.

@waldyrious
Copy link
Collaborator

waldyrious commented Aug 26, 2021

In this PR the getSection commit is more of a change and the setText commit is a fix, but altogether I eventually settled on the Changed section header.

Good call. By the way, that reminds me of a comment I read a while ago: "all changes are potentially breaking, including so-called "bug fixes", which are just breaking changes where we have made a judgement call that no one is likely to have been relying on the old behavior."

(and, of course, the relevant xkcd 😄)

@Xymph Xymph force-pushed the 129-error-return-values branch 2 times, most recently from eed4aff to 770b268 Compare August 26, 2021 21:22
Copy link
Collaborator

@waldyrious waldyrious left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a tiny nitpick 😅

Comment on lines +18 to +22
#### Fixed

* Fixed one error return value in `WikiPage::setText()` ([#129])

Copy link
Collaborator

@waldyrious waldyrious Aug 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aw, come on, don't make me feel bad for requesting these lines to be added in the first commit 😅 (Or at least, have the changelog update as a separate commit to either change.)

Copy link
Collaborator Author

@Xymph Xymph Aug 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No intention to do that, but I'm not sure what you're aiming for. Should I move the getSection changelog entry into the first commit with the code change, or split off something into a third commit? How? Figured something out. Hmm, that didn't work yet.

Ok, I give up, bedtime for me.

Copy link
Collaborator

@waldyrious waldyrious Aug 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I move the getSection changelog entry into the first commit with the code change, or split off something into a third commit?

Either should work. Probably having the changelog in a separate commit is easier, but here's how I'd do both:

  1. git rebase -i master, change the first commit's line in the rebase editor from pick to edit, and when the rebase pauses there, I'd make the change to the changelog and then git commit --amend, git rebase --continue. Hopefully git would automatically detect the duplicated changes in the second commit and simply apply the difference.

or

  1. git reset HEAD~ (which I have aliased to git uncommit, btw) to undo the latest commit and leave its changes in the working directory, then git add Wikimate.php, make the commit, and then git add CHANGELOG.md and make that commit.

Since you're gone and I've given you this trouble, let me see if I can do it myself.

Copy link
Collaborator

@waldyrious waldyrious Aug 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, option 1 worked. Git was smart enough to finish the rebase cleanly for me :) I'll go ahead and merge. Once again, sorry for the trouble! 😅

@Xymph Xymph force-pushed the 129-error-return-values branch 4 times, most recently from b698485 to ea2bfec Compare August 26, 2021 22:00
@waldyrious waldyrious force-pushed the 129-error-return-values branch from ea2bfec to f8f42ce Compare August 26, 2021 22:27
@waldyrious waldyrious merged commit 9bec877 into hamstar:master Aug 26, 2021
@Xymph Xymph deleted the 129-error-return-values branch August 27, 2021 08:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants